22.03.14 - Config Development
- Version control
- Continuous Integration
- Build Configurations
- Automatic Deployment
Version Control
- From git can pull old versions of code. Can create a branch which represents v2.5
- Many strategies for using version control, manage versions and to see the expected reading
- Have different ways of branching, can branch for release, maintenance, feature, team. All depends on the company
- Need to always have a safe version in working mainline, don't want to damage it. Instead work on a branch off these mainlines
- Only once everything passes tests in branch, can then merge it into mainline
- Only head developers have access to modify the main branch, so no damage gets pushed. Someone always has the responsibility to protecting the mainline.
Continuous Integration
Code changes go directly into mainline of version control
- automatically builds complete software as submitted, release-tests all new contributions
- successful build == accepted submission.
- Always have a working mainline in version control
- Have automatic build scripts to deploy them
Benefits:
- Supports TDD - all submissions need to integrate successfully
- Integration [and testing] is figured out form the start
- Identifies bugs quickly because integration happens sooner
Build Configurations
Configuration for a new version includes:
- Versions of components are included
- Which platform-specific libraries to bundle in
- Which test suite to perform
- Where to deploy the build
A release is then built based on the configuration, several versions can be created for different platforms
Companies are always refining build configs and scripts
Automatic Deployment
Like jamies auto marker